Recently, there has been an explosion in the number of wireless devices (e.g. cellular and digital PCS phones, pagers, wireless modems, PDAs, etc.) in use. These numbers continue to grow dramatically and are predicted to do so for the foreseeable future. Along with this growth is a demand for bringing Internet applications (e.g. web browsing, e-mail) to the wireless device. However, such applications suffer from slow transmission speeds and the need to build wireless Internet infrastructure piece by piece with each new application.
FIG. 1 illustrates the existing Internet/World Wide Web (WWW) model. As shown in FIG. 1, a client 102 coupled to the Internet communicates with an origin server 104 also coupled to the Internet. A user agent (e.g. browser) 106 in the client sends requests for one or more named data objects (or content) 110 to an origin server by specifying the Uniform Resource Locator (URL) of the data object. The origin server 104 responds with the requested data expressed in one of the formats known to the user agent (e.g. Hypertext Markup Language (HTML)). The URL from the user agent may specify a data object already in a known format such as HTML, or the URL may specify a server application such as a CGI script 108 that generates content in one of the known content formats. The user agent 106 can communicate with the origin server 104 using a known protocol such as Hypertext Transfer Protocol (HTTP).
The wireless Internet model in accordance with the Wireless Application Protocol (WAP) closely follows the WWW model, the wireless model being illustrated in FIG. 2. As shown in FIG. 2, the wireless model further includes a gateway 204 that is responsible for encoding and decoding data transferred from and to the mobile client. One of the purposes of encoding content delivered to the client is to minimize the size of data sent to the client over-the-air as well as to minimize the computational energy required by the client to process that data. Although shown in FIG. 2 as a separate dedicated device, the functionality of the gateway may actually be incorporated within an origin server. The gateway further must perform functions for managing the traffic flowing between the origin server and the mobile client, including session management and protocol conversion.
The client 202 resides in a wireless device so as to provide specific functionality (e.g. display content) to the wireless user. User agents (such as browsers) 306 can be integrated into the client. They interpret network content referenced by a URL. Typically, user agents include functionality for interpreting two primary standard types of content: encoded Wireless Markup Language (WML) and compiled Wireless Markup Language Script (WMLScript).
In operation, user agents can communicate with the gateway 204 using Wireless Session Protocol (WSP). The gateway in turn provides protocol conversion functions to connect to an HTTP origin server. For example, a user, with a WAP-compliant telephone, requests content using a specific URL. The telephone browser (i.e. user agent 206) connects to the operator-controlled gateway with WSP and sends an encoded GET request with that URL. The gateway decodes the request, resolves the host address specified by the URL and creates an HTTP session to that host. The gateway then performs a request for the content specified by the URL. The HTTP server at the contacted host processes the request and sends a reply (e.g., the requested content). The gateway 204 receives the content from the origin server 104 and encodes it using an encoder (i.e. tokeniser) 208 that converts the content from a textual format to a binary format. The gateway then returns the encoded content to the browser 206.
Two popular design patterns are dominating today's WAP implementations: WAP Gateway/Proxy and WAP Server. Both are characterized by centralized software processing of WAP content. While this kind of software based implementation, crossing all general platforms such as NT and Unix, is a straight forward and intuitive approach adapted to the infancy stage of an industry standard such as WAP, it introduces many pitfalls and inefficiencies.
For example, most wireless gateways are pre-configured to handle only one type of cellular infrastructure or standard such as CDPD, Bell South Wireless Data (RAM), GSM, CDMA, TDMA, AMPS, D-AMPS, Ardis, FLEX/ReFLEX, Mobitex, DataTec, etc. and one type of wireless application protocol such as HTTP, WAP, HDML, cHTML, Web clipping. Accordingly, a carrier or service provider with a large customer base is forced to deploy multiple gateways with specific functionality to support the customers' infrastructure or protocol. Moreover, as new applications are developed such as TSL/WTSL and other security applications, the gateway must be replaced. Alternatively, if such new functionalities are added to the server, the processing power and server resources that they consume can cause the performance of the gateway to decrease.
Further, such standard or protocol-specific gateways are dedicated servers that are not fault-tolerant or load-balanced because it is generally not feasible or simple to provide multiple gateways and link them together with fault tolerance or load balancing functionalities.
As set forth above, the gateway is responsible for maintaining and managing connections with wireless devices in accordance with wireless protocols. FIG. 3 illustrates the WAP model for layering protocols in communications with wireless devices. It should be apparent that this model is similar to that of the ISO OSI Reference Model (ISO 7498) for upper layers. As shown in FIG. 3, on top of the underlying bearer service (e.g. GSM) are, respectively, a transport layer (e.g. WDP/UDP), a security layer (e.g. WTLS), a transaction layer (e.g. WTP), a session layer (e.g. WSP), and an application layer. The security layer and transaction layer may be considered as optional.
FIG. 4 illustrates a conventional gateway that can be used in the wireless model shown above. As shown in FIG. 4, in the conventional gateway 400, a network interface 402, a wireless data interface 404, a CPU 406, a program memory 408 and a data memory 410 communicate with each other via a bus 412.
In operation of the gateway illustrated in FIG. 4, data from the wired and wireless data networks are received at the network and wireless data interfaces, respectively, and buffered at the interfaces. At appropriate intervals, the CPU 406 is interrupted and causes the data in the interface buffers to be transferred to the data memory 410. The individual software tasks residing in the program memory 408 are selectively executed to operate on the data in the data memory so as to perform content conversion, protocol conversion, and session management, etc. Upon completion of the appropriate processing, the data is transferred back to the buffer of the appropriate interface and forwarded on the appropriate network.
The above conventional gateway implementation is very rudimentary and represents the least overall efficiency and the longest system latency, as will be explained in more detail below.
First, general purpose servers are typically used to implement the gateway 400 shown in FIG. 4. Such general purposed servers are loaded with heavy-weighted operating systems, which are not optimized for WAP related processes. Further, general purpose servers are bundled with other features such as supporting a keyboard, CD ROM, video and audio cards and other non-network related peripherals, which burden the CPU with much system overhead. A light-weighted embedded real-time operating system is desired.
Another drawback is that these servers are equipped with basic network adapters for implementing the network and wireless data interfaces 402 and 404. Such adapters rely completely on the host CPU to process the packets, and thus the host CPU exclusively handles network traffic processing. These kinds of network adapters place a heavy load on the host CPU in at least two ways. First, the adapter interrupts the host upon receipt of network data, and this interrupt causes two context switching operations on the host, a costly function in terms of CPU utilization. Second, data received by the adapter has to be processed layer through layer by respective engines 418 executing in a general operating system (e.g. NT or Solaris) residing in the host environment. Similarly, outgoing data must be packaged layer through layer by these non-optimized engines 418 before the adapter transmits it. Depending on the implementation, this layering processing may be very CPU intensive, and further, totally unnecessary given the purpose of WAP Gateway.
The lack of intelligence on these network adapters often results in multiple interrupts being issued for host notification, and each packet being copied and processed multiple times. The ideal design should be the one that moves the data around as less as possible. Finally, many designs are thread or process based. Every wireless user request will invoke an independent thread to handle it. The problem with this approach is that every thread has a structure created by the OS and its processing totally relies on the scheduling of the OS, i.e. the sequence of handling the requests. Under the newly deployed packet based wireless data network, thousands or more users can be online simultaneously. A correspondingly large number of threads can be extremely resource hungry and can cause the host system to be unstable at best and to crash at worst. This scenario has actually happened in I-Mode service because of the packet-based feature of the service networks and the large user base.
The conventional gateway illustrated in FIG. 4 suffers from even further drawbacks. For example, in operation as explained above, incoming data (e.g. WML text, perhaps in response to a request from a wireless user via a URL) from the wired network (e.g. the Internet) is buffered at the network interface. When a complete packet has been received, the network interface interrupts the CPU, which causes the packet to be transferred to the data memory via the bus. Then the CPU executes an encoder program 414 in the program memory to encode the data into binary format suitable for the wireless data network. The encoder program works on the data from the data memory, stores the encoded data back into the data memory, and interrupts the CPU, which then causes the encoded data to be sent to the wireless data interface, where it is buffered then sent out to the appropriate wireless destination. Similarly, incoming encoded data is buffered at the wireless data interface, transferred to the data memory, decoded by decoder program 416 and stored back into the data memory, then transferred back to the network interface for transmission to the appropriate network destination.
It should be apparent that the conventional gateway requires much CPU intervention and excessive transfer of data between elements and functions. Moreover, the scalability limitation of this design under heavy traffic and processing loads render this architecture suitable for sites with only low traffic expectation and simple traffic management requirements.
Not only is the design of FIG. 4 currently unsatisfactory for many purposes as illustrated above, it will grow more unsatisfactory in the future. For example, the pending WAP 2.0 specification, with the support of graphics and multimedia and the commercial deployment of packet based wireless data network such as GPRS, will dramatically accelerate the development of wireless Internet applications with even further complexity and dynamics. While the wireless Internet represents new ventures for application developers and complementary experiences to the end users, the fundamental network and traffic management requirements from the service providers' viewpoint are the same as that of the existing wired internet: reliability, scalability, easy management and cost effective. The current wireless gateway architecture does not adequately address these requirements.